A service-oriented architecture (SOA) is an architecture that uses loosely coupled services to support the requirements of business processes and users. By a service is meant a mechanism to enable access to one or more capabilities, where the access is provided using a prescribed interface and is exercised consistent with constraints and policies as specified by a service description. By loose coupling is meant a resilient relationship between two or more services with some kind of exchange relationship as described in Doug Kaye, “Loosely coupled: the missing pieces of web services”, RDS Press, Marin County California, 2003. The “OASIS Reference Model for Service Oriented Architecture 1.0” published by the Organization for the Advancement of Structured Information Standards (OASIS) at “http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=soa-rm” describes a reference model of a SOA.
FIG. 1 shows, as an example, a block diagram of an electronic commerce application 100 in accordance with a SOA, illustrating a typical access pattern for a virtual shopping cart. In step 110, a controller 101 requests the contents of a shopping cart 106, for example, in response to a user query to view contents of the shopping cart or as a part of making a purchase. In step 111, the controller 101 receives the list of items contained in the cart 106, for example, from an underlying database. In step 112, the controller 101 processes the list of items, typically through the consolidation 102 of multiple items identifying the same article into a single item of the respective accumulated quantity. In step 113, the controller 101 requests the articles identified by the consolidated shopping cart items and receives the articles in step 114. Finally, in step 115, the controller performs a match 103 between the retrieved articles and the shopping cart items. Here, access to the shopping cart 106 is managed by means of a cart service 104, whereas access to the catalog 107 is managed by means of a catalog service 105.
When defining the services of a SOA, storage and information service interfaces are commonly modeled in the same fashion and using the same tools and techniques as other services. This conventional approach does not take into account the specific requirements of storage and information services. In particular, the resulting service definition typically does not include a persistent data model, that is, an abstract model that describes how data is represented and used which outlives the execution of the service that created it. The state-of-the-art service definition only defines the interface between components. It does not comprise the persistent data model underlying a component implementing a service using persistent data.
An example of a conventional persistent data meta-model, i.e. a model for modeling persistent data, is given in FIG. 2. The meta-model 200 comprises the object types “Relation” 201, “Object” 202, and “Attribute” 203, which are described in the following.
An object 202 contains the name of the object (i.e. a representation of the table name in a conventional data store). An attribute 203 is related to the object 202, and contains the name and type of the attribute 203. It further comprises information on whether the attribute 203 is part of the primary key of the object 202. The primary key uniquely identifies the object 202 in the persistent data store and consists of the set of attributes that are marked as part of the primary key.
A relation 201 defines a foreign key relationship between objects 202. The relationship is directed, i.e. when a first object has a foreign key relationship to a second object, the first object has attributes that contain the value of the primary key of the second object. Using the foreign key relationship, the attributes of the first object containing the primary key of the second object may be automatically generated and thus not explicitly defined in the set of attributes for the first object.
Since it does not include the persistent data model, the state-of-the-art service model does not allow the efficient generation of an implementation for the service it defines. This can result in a mismatch between the service interface and the requirements of the information architecture and lead to performance problems in the actual implementation of the service.